Capitolul 3 Proiectarea arhitecturii programelor 


3.1 Definirea arhitecturii programelor 


Arhitectura unui sistem informatic face referire la structura sa. Conform 
teoriei generale a sistemelor, prin structură se descriu elementele 
componente ale sistemului, interconexiunile între acestea, pe de o parte, între 
acestea şi sistem, pe de altă parte. Noţiunea de structură poate fi definită din 
perspectiva transformărilor prin care trece sistemul în interacţiunea cu 
mediul său, considerându-se că ea face referire la aspectul invariant al 
sistemului, dând identitatea acestuia. Astfel, structura unui sistem defineşte o 
ordine relativ stabilă, referindu-se la anumite caracteristici invariabile în 
condiţiile variabilităţii intrărilor, ieşirilor şi stărilor sistemului. 

Prin transpunerea celor prezentate anterior, structura unui sistem 
informatic face referire la modul de organizare a componentelor sistemului, la 
identitatea sa, la ceea ce-i conferă o anumită stabilitate. Într-o mainieră 
generică, arhitectura unui sistem informatic defineşte componentele acestuia, 
proprietăţile lor vizibile din exterior, precum şi relaţiile dintre componente. 
Concretizarea definiţiei anterioare, presupune specificarea semnificației 
atribuite noţiunii componentă, după care vor putea fi identificate clar 
proprietăţile lor şi natursa relaţiilor dintre ele. 

În funcţie de semnificaţia noţiunii “componentă”, arhitectura sistemelor 
informatice poate fi definită într-un sens restrâns şi unul larg. În sens 
restrâns, proiectarea arhitecturii unui program vizează componentele 
programului, respectiv modulele acestuia, însă ea poate fi extinsă prin 
includerea bazei de date şi a componentei middleware care permite 
configurarea comunicării într-un sistem client-server. Proprietăţile acestor 
componente sunt acele caracteristici care permit înţelegerea modului în care 
ele interacționează, respectiv modul de apelare a unui modul din alt modul 
sau mecanismul de accesare a bazei de date de către modulele programului. 
Proiectarea arhitecturala a programului nu ia în considerare proprietăţile 
interne ale componentelor, cum ar fi detaliile unui algoritm specifice unui 
modul. Relaţiile dintre componente se pot referi fie la apelarea unei 
proceduri, cu transmiterea eventuală a datelor necesare execuţiei procedurii 
respective, fie la protocolul de accesare a bazei de date de către procedurile 
de program. 

Din cele prezentate anterior, reiese că poate fi vorba de două paliere ale 
structurii uni sistem informatic: proiectarea stucturii datelor, respectiv a 
bazei de date, şi proiectarea structurii programelor. În acest capitol ne vom 
ocupa de arhitectura programelor. 

Continuarea demersului propus impune clarificarea noţiunii „modul”. 
Modulul poate fi considerat o unitate structurală de sine stătătoare, fie 
program, fie subprogram, fie o unitate de program, fiind văzut ca o colecţie 
sau o formă grupată de instrucţiuni program. Fiecare modul va avea un 
singur punct de intrare şi un singur punct de ieşire. Astfel definit, modulul 
reprezintă o unitate distinctă din perspectiva operaţiei de compilare. Însă, 
aceeaşi noţiune poate fi utilizată pentru a referi o unitate distinctă în 
proiectare. De cele mai multe ori, unei astfel de unităţi îi corespunde o 
procedură de program (în cazul arhitecturii modul principal/subprograme), 
dar există şi situaţii în care unui modul poate să-i corespundă două sau mai 
multe proceduri de program (cum este cazul arhitecturii tip de date 


abstracte). Aşadar, noţiunea de modul este mai degrabă una intuitivă decât 
una riguros definită. Totuşi, cert este că un modul prezintă trei atribute de 
bază, prin intermediul cărora el poate fi descris: funcţia, logica şi interfaţa. 

Funcţia unui modul face referire la transformările realizate asupra 
datelor în urma execuţiei acestuia. Funcţia este tratată în regimul cutiei 
negre, adică ea este văzută prin ceea ce se percepe din exteriorul modulului, 
respectiv intrările, ieşirile şi rolul modulului, fără a privi componentele 
interne ale modulului(instrucţiunile şi logica modulului). 

Logica modulului descrie prelucrările ce au loc în interiorul acestuia, 
respectiv componentele modulului şi logica înlănţuirii acestor componente. Cu 
alte cuvinte, logica modulului specifică modul în care sunt transformate 
intrările în ieşiri. Algoritmii de prelucrare pot fi redaţi cu ajutorul schemelor 
logice, pseudocodului, tabelelor de decizii sau combinaţii ale acestora. 

Interfeţele sunt legăturile dintre module, şi pot apare sub forma 
transferării controlului execuţiei programului de la un modul la altul şi al 
transmiterii de date de la un modul la altul. 

Arhitectura programelor prezintă o mare importanţă în activitatea de 
proiectare din cel puţin patru motive!: 

> Conceperea arhitecturii programului permite o mai bună 
comunicare între părţile interesate în dezvoltarea sistemului 
informatic, pe baza ei putându-se discuta şi analiza inclusiv 
aspectele calitative relevante ale programului; 

> Arhitectura evidenţiază principalele decizii de proiectare care au 
un impact profund asupra activităţilor ulterioare privind 
dezvoltarea programului şi în succesul acestuia; 

> Arhitectura oferă un model relativ simplu al modului în care este 
structurat sistemul şi modul în care componentele sale 
interacționează; 

> Arhitectura reprezintă o unitate transferabilă a sistemului 
informatic, ea stând astfel la baza reutilizării atât în cazul unor 
sisteme similare, cât şi al reproiectării sistemului. 

După ce am văzut în ce constă arhitectura sistemelor informatice şi 
importanţa ei în dezvoltarea lor, în continuare vor fi detaliate principalele 
probleme privind proiectarea arhitecturală a programelor, respectiv modelele 
arhitecturale ce pot fi utilizate, căile de obţinere a arhitecturii, conţinutul 
specificaţiilor de proiectare arhitecturală şi criteriile cantitative şi calitative 
de evaluare a arhitecturii programelor. 


3.2 Structura ierarhică de control 


În afara identificării componentelor şi a naturii legăturilor dintre ele, 
orice sistem implică şi o anumită formă de organizare. Deşi până în prezent 
au fost d sute de mii de sisteme informatice, marea lor majoritate pot 
fi încadrate într-un număr mic _P_lodele arhitecturale. Cea mai cunoscută în 
lumea proţramelor este (în olgănizal ->rarhică a modulelor prezentată 
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F Figura 3.1 Structura arborescentă inversă a unui program 

Intr-o structură ierarhică, modulele sunt grupate pe niveluri ierarhice, 
în care un modul poate fi apelat numai de modulele situate pe nivelurile 
ierarhice superioare, el fiind considerat subordonat modulelor care-l apelează, 
în timp ce modulul care apelează un modul subordonat este referit ca 
supervizor (sau modul de control). De exemplu, modulul P este supervizor 
pentru modulele a, b şi c, iar modulul g este subordonat modulelor d şi e, iar 
în ultimă instanţă, modulului P. 

În scopul unei mai bune evaluări a arhitecturii ierarhice a programelor 
au fost introduse unele mărimi cantitative. Ele sunt sunt considerate ca fiind 
de tip „cutia neagră”, deoarece ele nu implică cunoaşterea detaliilor interne 
ale modulelor. Cele mai simple mărimi arhitecturale sunt: 

> Dimensiunea, calculată ca numărul de noduri din structură, 
numărul arcelor sau ca suma acestora. Arhitectura ierarhică a 
programelor poate fi văzută ca un graf, în care modulele 
reprezintă nodurile grafului, iar arcele corespund legăturilor 
dintre module. 

> Adâncimea (depth), indică numărul nivelurilor ierarhice din 
structură, luându-se în calcul calea cea mai lungă de la rădăcină 
până la un nod frunză. 

> Lățimea (width), reprezintă numărul nodurilor de pe nivelul 
ierarhic cu cele mai multe noduri. 

> Fan-out, este o mărime calculată pentru fiecare modul ca numărul 
modulelor controlate în mod direct de către modulul respectiv. 

> Fan-in, calculată de asemenea pentru fiecare modul şi reprezintă 
numărul modulelor care controlează (apelează) în mod direct 
modulul respectiv. 

Aceste mărimi elementare stau la baza calculării mai multor indicatori 
prin intermediul cărora se poate face o mai bună evaluare asupra arhitecturii 
programului, prin comparaţie cu alte programe. De exemplu, raportul dintre 
numărul arce şi numărul de noduri măsoară nivelul conectivităţii arhitecturii 
şi oferă o imagine generală asupra gradului de cuplare a sistemului (cuplarea 
este un indicator de apreciere calitativă a arhitecturii programelor, asupra 
căruia vom reveni în finalul capitolului). 

Numeroşi specialişti au propus chiar seturi de indicatori pe baza cărora 
să se analizeze arhitectura programelor. Astfel, Card şi Glass au definit trei 
indicatori pentru aprecierea complexităţii arhitecturale: 

> Complexitatea structurală a unui modul, calculată după formula: 
S(i) = FO?(), 
în care FO reprezintă indicatorul fan-out pentru modulului i. 


> Complexitatea datelor se referă la complexitatea interfeţelor unui 

modul, fiind calculată după formula: 

D(i) = v(i) /[FO(G) + 1], 
în care v(i) reprezintă numărul variabilelor care intră şi care ies 
în/din modulul i. 

> Complexitatea sistemului este definită ca suma celor două mărimi 
definite anterior, respectiv C(i) = S(i) + D(i). Pe măsură ce aceste 
mărimi cresc, va creşte şi complexitatea sistemului, deci şi 
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Figura 3.2 Partiţionarea structurală a programelor 


Conceperea structurii ierarhice a programelor poate fi realizată prin 
partiţionarea orizontală sau verticală?. Partiţionarea orizontală presupune 
definirea unor ramuri separate în cadrul structurii ierarhice pentru fiecare 
funcţie principală a programului (vezi figura 3.2.a), în care modulele de pe 
nivelurile superioare vor asigura controlul execuţiei programului pentru 
realizarea funcţiilor respective, cât şi comunicarea între acestea. Cea mai 
simplă abordare a structurării orizontale presupune definirea a trei funcţii: 
introducerea datelor, prelucrarea lor şi generarea ieşirilor. Partiţionarea 
verticală presupune distribuirea top-down a controlului şi a prelucrărilor în 
structura programului, astfel încât modulele situate pe nivelurile superioare 
realizează funcţiile de control ale programului, iar cele de pe nivelurile 
inferioare realizează prelucrările propriu-zise, respectiv introducerea datelor, 
transformarea lor şi generarea ieşirilor (vezi figura 3.2.b). 

Din punctul de vedere al efectelor propagate în structura programului 
de eventualele modificări ale programelor, este indicată partiţionarea 
orizontală, deoarece separarea funcţiilor duce la obţinerea de programe mai 
uşor de întreţinut şi testat, dar şi mai uşor de extins prin adăugarea unor noi 
funcţii. Atât timp cât majoritatea modificărilor în programe au loc la nivelul 
funcţiilor pe care le realizează, este evident că se vor produce mai puţine 
efecte asupra celorlalte părţi ale programului. În cazul partiţionării verticale, 
modificările la nivelul modulelor superioare, care realizează controlul 
programului, vor avea o probabilitate mai mare de propagare a efectelor în 
modulele subordonate, chiar dacă modificările la nivelul modulelor situate pe 
nivelurile inferioare sunt mai puţin susceptibile de propagarea efectelor. 

În schimb, partiţionarea orizontală presupune, adesea, transmiterea 
unui volum mare de date de la un modul la altul, ceea ce face complexă 
interfaţa dintre module şi complică pe ansamblu fluxul logic de control al 
programului, mai ales în cazul în care prelucrările solicită numeroase 
transferuri ale controlului de la o funcţie la alta. Prin urmare, alegerea 
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modului de structurare (partiţionare) a modulelor programelor se va face în 
funcţie de caracteristicile sistemului informatic. 


3.3 Diagrama de structură 


Diagrama de structură reprezintă principalul instrument grafic de 
proiectare a sistemelor informatice. Ea redă structura fizică a programelor 
sub formă arborescentă. Dacă diagramele fluxurilor de date pun în evidenţă 
cerinţele funcţionale şi fluxurile informaţionale ale sistemului iar diagrama 
entitate-relaţie arată entităţile de date şi legăturile dintre acestea, diagrama 
de structură evidenţiază modul de organizare fizică a componentelor 
programelor din sistem. Aspectele arhitecturale ale sistemelor informatice, 
prezentate în paragraful anterior, sunt general valabile indiferent de 
formalismul sau metoda de proiectare aleasă. Modul de transpunere a lor în 
diagrama de structură înregistrează însă unele diferenţe, mai mici sau mai 
mari, în ce priveşte simbolurile utilizate şi regulile de concepere a 
diagramelor. Prezentarea din acest paragraf are la bază metoda 
Yourdon&Constantine. 
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Figura 3.3 Elementele componente ale diagramei de structură 


Obiectivul urmărit prin construirea diagramei de structură constă în 
reliefarea componentelor (modulelor) unui program, a legăturilor dintre 
aceste componente (adică modul de invocare a modulelor şi datele transmise 
de la un modul la altul), precum şi a structurilor de control specifice 
programării structurate (secvenţa, selecţia şi iteraţia). In acest sens, la 
construirea diagramei de structură se apelează la simbolurile prezentate în 
figura 3.3. 

Modulul, principala componentă a unui program, este reprezentat 
printr-un dreptunghi în care este înscris numărul de identificare şi numele 
său. Numele unui modul specifică funcţia acestuia. La numirea modulelor vor 
fi evitate elementele de legătură, („şi”, „-„) ceea ce denotă că modulul 
respectiv realizează mai mult decât o singură funcţie şi ar putea fi necesară 
descompunerea acestuia. 

O diagramă de structură are un singur modul coordonator, situat în 
vârful diagramei, care va putea apela modulele situate pe nivelul 2. Acestea, 
la rândul lor, vor apela modulele situate pe nivelul 3 ş.a.m.d. In cazul 
aplicaţiilor care dispun de un meniu, diagrama de structură poate fi 


concepută astfel încât modulul coordonator să reprezinte meniul principal, iar 
modulele subordonate vor corespunde opţiunilor din meniul principal. 

Invocarea modulelor programului de către alte module poate presupune 
şi transmiterea parametrilor de lucru sub forma datelor elementare sau a 
structurilor de date (data couple) şi/sau a informaţiilor de control (control 
couple). O informaţie de control reprezintă o dată necesară în prelucrările 
realizate de modulul care o primeşte, iar în funcţie de valoarea ei se va 
efectua o prelucrare sau alta; spre deosebire de structurile de date 
elementare, o informaţie de control nu va fi supusă transformărilor în modulul 
care o recepționează. Structurile de date transmise între module sunt 
reprezentate printr-o săgeată cu un cerculeţ neumplut care arată direcţia în 
care sunt transmise datele. Reprezentarea informaţiilor de control se face tot 
printr-un cerculeţ cu săgeată, numai că de această dată cerculeţul este 
umplut (vezi şi figura 3.3). 


Figura 3.4 Redarea secvenţei în diagrama de structură 


Pentru o mai bună claritate şi sugestivitate, în diagrama de structură 
pot fi reprezentate şi structurile de control caracteristice programării 
structurate. Secvența este pusă în evidenţă prin citirea diagramei de la 
stânga la dreapta. Apelarea modulelor subordonate de către modulul de 
control, deci şi citirea diagramei, se va face de la stânga la dreapta. În cazul 
în care este imposibilă aranjarea modulelor în ordinea invocării lor de la 
stânga la dreapta, atunci ordinea apelării lor va putea fi pusă în evidenţă prin 
aranjarea în ordinea corespunzătoare a săgeţilor la intersecţia cu modulul de 
control, după cum este prezentat în figura 3.4. În acest caz, unele din săgeți 
se vor intersecta între ele. În figura 3.4, modulul de control C va apela mai 
întâi modulul F şi apoi modulul E. 

Selecţia este pusă în evidenţă printr-un romb. Acest simbol se va utiliza 
atunci când se doreşte reprezentarea faptului că doar unul din mai multe 
module subordonate poate fi apelat de modulul de control sau că un modul 
modul va fi apelat numai dacă este întrunită o condiţie (vezi şi figura 3.3). 
Toate modulele implicate în selecţie vor fi conectate prin linii de invocare 
prevăzute cu un romb, cu excepţia modulelor care vor fi apelate de fiecare 
dată. 

Iteraţia este reprezentată printr-o linie curbă trasată peste liniile de 
invocare care leagă modulul respectiv de modulele subordonate apelate în 
mod repetat de modulul de control. Linia curbă nu va intersecta liniile de 
invocare pentru modulele care vor fi apelate o singură dată. 

Dacă pentru modelarea unui sistem informatic este necesară 
construirea mai multor diagrame ale fluxurilor de date, în schimb va exista o 
singură diagramă de structură. De aceea, oricât de simplu ar fi sistemul în 
cauză, construirea diagramei de structură se va face pe mai multe pagini, 
ceea ce implică utilizarea conectorului de pagină pentru a indica faptul că 
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diagrama se continuă pe altă pagină. Dacă se doreşte continuarea diagramei 
pe aceeaşi pagină dar în alt loc decât cel normal (de exemplu am ajuns în 
partea de jos a paginii de lucru, însă în partea sa superioară mai există loc 
suficient) atunci se poate apela la conectorul în cadrul paginii. Simbolurile 
pentru ambele tipuri de conectori sunt prezentate în figura 3.3. Ambele tipuri 
de conectori trebuie să conţină o etichetă prin intermediul căreia să se facă 
legătura. 

Diagrama de structură este utilizată pentru descrierea arhitecturii 
programelor scrise în limbajele din generaţia a treia sau a patra. Dacă se va 
utiliza un limbaj de programare orientat-obiect sau orientat pe evenimente, 
atunci se va apela la diagrama stărilor de tranziţie, diagrama istoricului vieţii 
entității sau a altor instrumente. Oricum, utilizarea diagramelor de structură 
permite obţinerea mai multor avantaje legate de activitatea de scriere a 
codului’. În primul rând, având la dispoziţie diagrama de structură, activitatea 
de programare se poate desfăşura după aceeaşi paşi logici după care s-au 
construit diagramele fluxurilor de date. De asemenea, aranjarea modulelor 
într-o structură ierarhică permite obţinerea unei arhitecturi a programului 
bine organizată şi uşor de gestionat. În sfârşit, dar nu în ultimul rând, 
diagrama de structură oferă o imagine globală asupra sistemului, înglobând 
toate componentele sistemului descrise în diagramele fluxurilor de date, 
diagrama entitate-relaţie şi dicţionarul de date. Acest lucru permite realizarea 
unei analize calitative detaliate a structurii programului, a modulelor 
componente, din pespectiva conceptelor şi regulilor practice de proiectare, 
permiţând localizarea şi corectarea uşoară a eventualelor erori de proiectare. 

Desigur că toate aceste avantaje nu pot fi obţinute fără anumite costuri; 
conceperea şi construirea unei bune diagrame de structură implică un efort 
considerabil, cu atât mai mare cu cât sistemul este mai complex. În plus, 
produsele CASE actuale nu realizează transformarea automată a diagramelor 
fluxurilor de date în diagrama de structură, astfel încât activitatea de 
concepere a diagramei de structură rămâne una exclusiv manuală. 


3.4 Aspecte privind proiectarea arhitecturii programelor 


După cum am văzut anterior, instrumentul cel mai comun în proiectarea 
structurată îl reprezintă diagrama de structură. Ea redă arhitectura 
programelor sub forma unei structuri ierarhice în care sunt evidenţiate 
relaţiile dintre module, fluxul de date de la un modul la altul şi transformările 
efectuate asupra datelor în cadrul modulelor. Principala problemă care se 
pune acum priveşte modul în care poate fi construită diagrama de structură 
astfel încât să fie înglobate toate cerinţele funcţionale ale sistemului în 
arhitectura programelor. 

În general, cerinţele funcţionale ale sistemului determină arhitectura 
sa, chiar dacă mai există şi alţi factori externi care o pot influenţa, precum 
experienţa anterioară a membrilor echipei de proiectare, mediul tehnic şi 
organizaţional al sistemului etc. Dacă în faza de analiză a sistemului cerinţele 
funcţionale ale sistemului au fost transpuse şi structurate sub forma unei 
ierarhii de mai multe diagrame ale fluxurilor de date, în faza de proiectare 
arhitectura programelor va fi redată cu ajutorul diagramei de structură. Prin 
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urmare, construirea diagramei de structură se va realiza pornind de la 
diagramele fluxurilor de date. 

Transpunerea diagramelor fluxurilor de date în diagrama de structură 
ar putea apare ca inutilă, atât timp cât cele două instrumente sunt 
asemănătoare, mai puţin în ce priveşte forma lor, dar mai ales în conţinut. La 
o succintă analiză se poate observa că atât diagramele fluxurilor de date cât şi 
diagrama de structură redau, într-o anumită secvenţă, procesele de 
prelucrare din sistem structurate de o manieră ierarhică, precum şi fluxurile 
de date transmise de la un proces de prelucrare la altul. În aceste condiţii, 
prin transpunerea directă a proceselor de prelucrare (diagrama fluxurilor de 
date) în module (diagrama de structură), s-ar putea obţine imediat diagrama 
de structură a sistemului. Atunci, ce sens ar mai avea construirea diagramei 
de structură şi de ce nu se transpun diagramele fluxurilor de date direct în 
programe? Dacă asemănările au fost evidenţiate, atunci în ce constau 
diferenţele dintre cele două instrumente? 

Răspunsurile la întrebările anterioare derivă din perspectivele diferite 
din care sunt construite cele două modele ale sistemului: diagrama fluxurilor 
de date este concepută din perspectiva utilizatorilor, pentru a asigura 
comunicarea dintre analiştii de sistem şi beneficiarii sistemului, în timp ce 
diagrama de structură este destinată programatorilor, asigurând comunicarea 
dintre aceştia şi proiectanţii sistemului. Chiar dacă se modelează aceeaşi 
entitate, se realizează din perspective diferite, deci şi limbajul de comunicare 
va fi diferit. De asemenea, prin construirea diagramelor fluxurilor de date se 
urmăreşte structurarea cerinţelor funcţionale ale sistemului, în timp ce prin 
diagrama de structură se descrie arhitectura programelor, ceea ce implică 
aplicarea unor principii şi reguli de lucru diferite. 

Cu toate eforturile depuse în faza de analiză şi la începutul fazei de 
proiectare logică, unele aspecte şi detalii esenţiale pentru activitatea de 
programare au fost omise. De exemplu, diagramele fluxurilor de date nu 
redau ramurile care tratează erorile, structurile de control alternative sau 
repetitive, informaţiile de control, operaţiunile detaliate de intrare/ieşire, sau 
structura programelor. Chiar dacă ar fi posibilă înglobarea acestor elemente 
în diagrama fluxurilor de date, ea nu este de dorit deoarece ar conduce la 
obţinerea unor diagrame nerelevante şi neinteligibile pentru utilizatori şi mult 
prea complexe pentru programatori, dar chiar şi pentru analiştii ce le-au 
construit. Mai mult, prin simbolurile şi notaţiile la care se apelează în 
construirea diagramei de structură se  uşurează mult sarcinile 
programatorilor, ele fiind mult mai aproape de limbajul de comunicare 
specific programatorilor. 

Pe de altă parte, după cum vom vedea în paragrafele următoare, 
diagrama de structură se obţine prin transpunerea directă a diagramelor 
fluxurilor de date doar într-o primă fază, ulterior ea fiind supusă unor 
operaţiuni de rafinare prin aplicarea unor concepte proprii programării 
calculatoarelor, precum coeziunea şi cuplarea, dar şi în funcţie de resursele 
hardware şi software ale sistemului. Dacă structura funcţională a sistemului, 
redată prin intermediul diagramelor fluxurilor de date, trebuie să reflecte 
relativ fidel funcţionalitatea sistemului (depinde de aptitudinile analistului), 
diagrama de structură trebuie să înglobeze unele obiective specifice 
activităţilor de proiectare şi programare cum sunt flexibilitatea, 
reutilizabilitatea, uşurinţa în implementare şi testare, uşurinţa modificării etc, 
precum şi unele restricţii de ordin tehnic precum capacitatea de memorie 


disponibilă, timpul de răspuns cerut, etc., chiar dacă aceste din urmă aspecte 
vor fi luate în considerare mai târziu în faza de proiectare. 

In concluzie, diagramele fluxurilor de date redau structura sistemului 
din perspectivă funcţională, în timp ce diagrama de structură redă structura 
sistemului din punct de vedere tehnic. Este evident că între cele două modele 
există numeroase legături, atât timp cât structura tehnică a sistemului este 
determinată de cerinţele sale funcţionale, dar există şi multe diferenţe care 
justifică necesitatea construirii lor pentru dezvoltarea sistemului. Maniera de 
obţinere a structurii programelor reprezintă o activitate distinctă în cadrul 
fazei de proiectare numită proiectarea arhitecturală. 

Proiectarea arhitecturală presupune găsirea soluțiilor privind 
descompunerea sistemului în părţi componente astfel încât fiecare parte să fie 
mai puţin complexă decât sistemul ca întreg, iar prin integrarea acestor 
componente sistemul să fie cât mai flexibil, să îndeplinească cerinţele 
funcţionale şi criteriile de calitate cerute de beneficiar, să îndeplinescă 
criteriile de calitate specifice programelor. În condiţiile în care complexitatea 
părţilor componente este rezonabilă, este foarte important ca interacţiunile 
dintre aceste componente să nu fie prea complicate. 


3.4.1 Transpunerea cerinţelor funcţionale ale sistemului în arhitectura 
programelor 


Transformarea diagramelor fluxurilor de date într-o arhitectură uşor de 
implementat reprezintă o activitate dificilă, pentru care nu există reguli 
stricte care ar putea fi urmate. Totuşi, literatura de specialitate prezintă 
câteva principii de lucru călăuzitoare şi chiar unele strategii bine definite care 
aduc o oarecare rigoare în proiectarea arhitecturală, asupra cărora ne vom 
opri în continuare. Oricum, această activitate rămâne una predominant 
intuitivă şi creativă. 

Inainte de a fi supuse transformării, diagramele fluxurilor de date 
trebuie revizuite în sensul detalierii lor. Această activitate mai este referită ca 
pregătirea diagramelor fluxurilor de date şi presupune parcurgerea mai 
multor paşi. 

Mai întâi, se va verifica dacă toate procesele din DFD realizează doar o 
singură funcţie. Fiecare proces identificat ca nefiind monofuncţional va fi 
descompus în două sau mai multe subprocese ce ar putea fi incluse într-o 
nouă diagramă de nivel inferior dacă diagrama care conţine procesul ce 
urmează a fi descompus conţine prea multe procese. Oricum, problema 
stabilirii dacă un proces este monofuncţional sau nu rămâne una relativă 
deoarece este greu de precizat dacă o funcţie mai poate fi descompusă sau ea 
poate fi considerată elementară. Unii specialişti au încercat să ofere soluţii în 
acest sens, pornind de la numărul de pagini de pseudocod necesare pentru 
descrierea procesului. O funcţie (proces) poate fi considerată elementară dacă 
detaliile logicii pot fi descrise pe cel mult o pagină (metoda 
Yourdon&DeMarco) sau între 5 şi 10 pagini de pseudocod (metoda 
Gane&Sarson)“. 

O altă soluţie porneşte de la numărul fluxurilor de intrare/ieşire în/dintr- 
un proces. Pentru a fi considerat elementar, orice proces trebuie să aibă doar 
o singură intrare sau o singură ieşire. În cazul în care un proces are mai 


t vezi Oprea, D., ş.a., CASE. Proiectarea asistată de calculator a sistemelor informatice, Ed. 
Univ. “Al. Cuza”, laşi 1998, p.53 


multe intrări şi mai multe ieşiri, se va considera că realizează două mai multe 
funcţii şi va fi descompus astfel încât fiecare subproces să aibă o singură 
intrare şi mai multe ieşiri sau mai multe intrări şi o singură ieşire. Oricum, 
problema nivelului până la care se va efectua descompunerea în diagramele 
fluxurilor de date rămâne la latitudinea analiştilor şi proiectanţilor implicaţi, 
în funcţie de complexitatea sistemului, aptitudinile şi experienţa lor. 

Pasul următor constă în adăugarea proceselor care privesc operaţiunile 
de citire, modificare şi ştergere a datelor din locurile de stocare, ce au fost 
omise până acum pentru claritatea diagramelor. Tot în acest moment, se va 
urmări legătura dintre diagrama fluxurilor de date şi modelul logic al bazei de 
date, dacă acesta a fost proiectat, şi eventual redat sub forma unei diagrame 
entitate relaţie (completată conform cerinţelor modelului relaţional). 

În final, vor fi adăugate alte detalii necesare activităţii de programare 
omise în faza de analiză, precum cele legate de editarea intrărilor, controlul 
validității datelor, tratarea excepțiilor generate de datele lipsă sau incomplete 
etc. Desigur că aceste elemente ar putea fi specificate în dicţionarul de date 
sub forma narativă mai mult sau mai puţin formalizată, iar ele vor fi luate în 
considerare la conceperea diagramei de structură fără a se mai realiza o 
detaliere a diagramelor fluxurilor de date. Acest aspect rămâne la latitudinea 
proiectanţilor implicaţi în proiectarea arhitecturală. 

După ce s-a încheiat operaţiunea de pregătire a diagramelor fluxurilor 
de date se trece la transformarea lor prin aplicarea uneia din două strategii 
posibile: analiza transformărilor sau analiza tranzacţiilor. Strategia 
(metoda) aleasă depinde de tipul sistemului informaţional. 

De regulă, sistemele informaţionale pot fi caracterizate ca fiind fie 
orientate pe transformări, fie orientate pe tranzacţii. Proiectanţii trebuie să 
identifice caracteristica sistemului (sau a unei părţi a acestuia) şi să aplice 
metoda corespunzătoare. Această caracteristică poate fi determinată în urma 
unei analize minuţioase a diagramelor fluxurilor de date. Analiza acestor 
diagrame trebuie realizată cu multă atenţie, deoarece pot exista sisteme 
orientate pe transformări, dar care să conţină părţi de sistem a căror 
caracteristică să fie orientarea pe tranzacţii, precum şi sisteme orientate pe 
tranzacţii care să conţină părţi de sistem care sunt orientate pe transformări. 
Oricum, majoritatea sistemelor informaţionale manifestă o caracteristică 
generală, în funcţie de care se va alege metoda ce va fi aplicată la început, 
după care se vor izola acele părţi ale sistemului a căror caracteristică diferă şi 
se va aplica strategia corespunzătoare. 

Sistemele orientate pe transformări au ca funcţie centrală derivarea 
informaţiilor de ieşire din datele de intrare prin aplicarea unuia sau a mai 
multor procese de prelucrare succesive. Transformările efectuate asupra 
datelor formează “nucleul” sistemului. În general, aceste transformări sunt 
transparente pentru utilizator, în sensul că interacţiunile cu utilizatorul sunt 
reduse ca număr sau chiar inexistente din momentul în care au fost iniţiate 
transformările. Sistemul de calcul al drepturilor salariale reprezintă un 
exemplu tipic pentru acest tip de sistem: pe baza numărului de ore lucrate 
(intrarea în sistem) se calculează drepturile salariale prin efectuarea 
diferitelor calcule privind tariful orar, sporurile şi reţinerile prevăzute, iar în 
final se vor obţine statul de plată şi centralizatorul statelor de salarii. Un alt 
exemplu îl reprezintă sistemul de contabilitate generală, a cărui funcţie 
principală o constituie înregistrarea cronologică şi sistematică a mişcărilor de 
valori ce au loc în firmă; notele contabile, preluate în sistem de la sistemele 
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de evidenţă analitică, sunt transcrise mai întâi în registrul jurnal, apoi ele 
sunt prelucrate şi sistematizate în cartea mare, pe baza căruia se va întocmi 
balanţa de verificare; prin aplicarea regulilor de transformare cunoscute, în 
final se va obţine bilanţul ce reprezintă principala ieşire a sistemului de 
contabilitate generală. 

Procesele dintr-o diagramă a fluxurilor de date pentru un sistem 
orientat pe transformări pot fi împărţite în trei categorii: 

> Procese aferente - sunt acele procese prin care se realizează 
introducerea datelor în sistem sau funcţia de editare a datelor de 
intrare. Mai multe module aferente pot fi grupate în ramuri 
aferente. 

> Procese eferente - sunt procesele care privesc furnizarea 
ieşirilor, ele putând fi de asemenea grupate în ramuri eferente. 

> Transformarea centrală - se referă la procesele care efectuează 
calcule şi prelucrări propriu-zise asupra datelor şi care formează 
la un loc ramura centrală. Diagramele fluxurilor de date pot 
conţine una sau mai multe ramuri centrale. 

În general, orice sistem informaţional poate fi văzut ca un flux de 
transformări, atât timp cât orice flux informaţional poate fi văzut ca o 
succesiune de transformări. Totuşi, unele sisteme se disting prin existenţa 
unui proces central, numit centru tranzacţional, al cărui rol constă în 
evaluarea tipului datelor de intrare şi în funcţie de care va declanşa 
prelucrările pe una din mai multe căi ce se desprind din el. Fiecare ramură 
care se desprinde din centrul tranzacţional conţine fluxurile şi procesele de 
prelucrare care tratează o anumită tranzacţie, astfel că vor exista atâtea 
ramuri câte tranzacţii sunt. De fapt, procesul care reprezintă centrul 
tranzacţional nu realizează nici o operaţie de transformare a datelor, ci are 
doar rolul direcţionării fluxului de date pe o anumită ramură, în funcţie de 
tranzacţia ce trebuie prelucrată. 

Un exemplu tipic pentru aceste sisteme îl reprezintă programele de 
actualizare a fişierelor (sau a bazelor de date), în care fiecare intrare în 
centrul tranzacţional va declanşa o tranzacţie de adăugare de noi înregistrări, 
o tranzacţie de modificare a unor înregistrări sau o tranzacţie de ştergere a 
unor înregistrări din fişier. Multe alte exemple se regăsesc în domeniul 
economic. Un sistem informaţional bancar prelucrează tranzacţii bancare 
precum: depuneri în cont, retrageri din cont, calculul şi înregistrarea 
dobânzilor etc. Sistemul informaţional pentru gestiunea stocurilor 
prelucrează tranzacţiile privind recepțiile de materiale, consumul de materii 
prime, darea în folosință a obiectelor de inventar, scoaterea din uz a 
obiectelor de inventar, transferuri de bunuri de la o gestiune la alta, vânzarea 
de produse etc. 

În aplicațiile on-line, fiecărei ramuri care se desprinde din centrul 
tranzacțional îi va corespunde o opţiune în sistemul de meniuri al aplicaţiei. 
Spre deosebire de sistemele orientate pe transformări, tratarea unei 
tranzacții presupune, de regulă, numeroase interacțiuni cu utilizatorul. 


3.4.1.1 Analiza transformărilor 


Pentru o mai bună sugestivitate a conceptelor şi operaţiunilor specifice 
metodei analizei transformărilor, vom apela la un model abstract. Pentru 
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început, vom porni de la diagrama fluxurilor de date prezentată în figura 3.55, 
a cărei orientare pe transformări este evidentă. După cum se poate observa, 
s-a apelat la notația Yourdon, în care ES şi ED reprezintă entităţile externe 
(ES - entitatea sursă, ED - entitatea destinaţie), LS1 şi LS2 sunt locuri de 
stocare a datelor, de genul fişierelor (sau a tabelelor bazei de date), iar 
cerculeţele simbolizează procesele de prelucrare. 

După analiza şi pregătirea diagramelor fluxurilor de date, transpunerea 
lor în diagrama de structură prin metoda analizei transformărilor presupune 
parcurgerea următorilor paşi: 

1.Izolarea ramurii centrale prin specificarea graniţelor cu 
ramurile aferente şi eferente ale DFD. Fluxurile de intrare specifică modul 
în care are loc conversia datelor din forma externă în cea internă, în timp ce 
fluxurile de ieşire se referă la conversia lor din forma internă în forma 
externă. Definirea acestor graniţe este relativ interpretabilă ceea ce face 
posibilă identificarea mai multor alternative de proiectare. Totuşi, aceste 
alternative vor avea un impact minim asupra arhitecturii finale a programului. 
Ramurile aferente sunt direcționate de la periferie spre centru şi conţin 
procesele care transformă intrările fizice în intrări logice, pregătite pentru 
realizarea funcţiilor principale de transformare. Operaţiuni tipice de 
transformare a intrărilor fizice în intrări logice se referă la: introducerea 
datelor, validarea lor, sortarea datelor de intrare etc. Ramurile eferente sunt 
direcționate din centru spre periferie. Ele grupează procese care realizează 
transformarea ieşirilor logice (date nestructurate, neformatate) în ieşiri fizice, 
pregătite pentru a fi furnizate entităţilor destinaţie. 


Se Ka LS2 
ia OO SRR | 

Ramur 
Ramur e! © f i 
i f eferen 
aferen Ramura to 
te j centrală de N m 

LS1 să transforma Su © ED | 
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Figura 3.5 Exemplu abstract de diagramă a fluxurilor de date orientată pe transformări 


Localizarea ramurii sau ramurilor centrale de transformare se poate 
realiza prin parcurgerea în sens normal a fiecărei ramuri aferente până când 
se întâlneşte primul proces care nu mai poate fi considerat ca proces aferent, 
determinându-se astfel granița până la care se întind ramurile aferente. Apoi, 
se parcurge în sens invers (din exterior spre interior) fiecare ramură eferentă 
până se identifică primul proces care nu mai poate fi considerat ca proces 
eferent, loc în care va fi stabilită granița până la care se intinde ramura 
eferentă. Ceea ce rămâne va reprezenta ramura sau ramurile centrale de 
transformare. 

În exemplul din figura 3.5, se observă că diagrama fluxurilor de date 
conţine două ramuri aferente (procesele A şi B, respectiv procesul C), două 
ramuri eferente (procesele G şi H, respectiv procesul F) şi o ramură centrală 
(formată din procesele D şi E). 


5 exemplul este adaptat după Powers, M.J., Cheney, P.H., Crow, G., Structured Systems 


Development: Analysis, Design, Implementation, Boyd & Fraser Publishing Company, 
Boston1990, citat în Oprea, D., Op.cit., p.405-413 
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2. Realizarea primei descompuneri şi construirea diagramei de 
structură de nivel superior. Structura programului va presupune o 
distribuire top-down a controlului (partiţionarea verticală): modulele situate 
pe nivelurile superioare vor rezolva problemele decizionale, motiv pentru care 
ele se mai numesc şi module de control, iar cele de pe nivelurile inferioare vor 
realiza majoritatea operațiunilor care privesc introducerea datelor, 
prelucrarea lor şi generarea ieşirilor. Modulele situate pe nivelurile de mijloc 
pot realiza câte puţin din ambele categorii de acţiuni. 

Structura de nivel superior obţinută printr-o primă transformare a DFD 
este prezentată în figura 3.6. După cum se observă, nu există o corespondenţă 
biunivocă între procesele din DFD şi modulele din diagrama de structură, 
unele module fiiind create de către proiectant. Astfel, a fost creat un modul 
principal care nu se regăseşte în DFD. De asemenea, au fost definite câte un 
modul de control pentru fiecare ramură aferentă, pentru fiecare ramură 
eferentă şi unul pentru ramura centrală de transformare. Modulele „Obținere 
d” şi „Obținere e” sunt modulele de control pentru cele două ramuri aferente; 
modulele „Plasare g” şi „Plasare h” corespund celor două ramuri eferente; 
modulul „Creare g,h” controlează ramura transformărilor centrale. 


Modulele eră 
corespunzătoare e 
ramurilor aferente 


P Modulele X 
„” pentru ramura Să 
centrală `~~-- 
Figura 3.6 Diagrama de nivel superior 
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Însă, numărul modulelor de pe primul nivel trebuie să fie minim în 
condiţiile menţinerii unui nivel bun de coeziune şi cuplare. De aceea, dacă 
numărul ramurilor aferente, eferente şi centrale este prea mare, atunci pe al 
doilea nivel vor fi create doar trei module de control, unul pentru ramurile 
aferente, unul pentru cele eferente şi unul pentru ramurile centrale, iar pe al 
treilea nivel al diagramei de structură se vor regăsi modulele de control 
corespunzătoare fiecărei ramuri aferente, eferente şi principale. 

3. Construirea diagramei de structură detaliate prin realizarea 
descompunerii de nivelul 2. În această etapă, are loc detalierea diagramei 
de structură printr-un proces iterativ de transpunere a transformărilor 
individuale din DFD în module de program. Va fi tratată fiecare ramură în 
parte, începându-se de la centru spre extremităţile ramurilor aferente şi 
eferente. 


h 
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Figura 3.7 Maparea ramurilor aferente şi eferente din DFD în arhitectura programului 


În etapa anterioară, „Obținere d” a fost identificat ca modul de control 
pentru ramura aferentă care are ca rezultat generarea lui d şi transmiterea 
lui în ramura centrală de transformare. Conform figurii 3.5, fluxul de date d 
este rezultatul procesului de transformare B care, la rândul lui, are ca intrare 
fluxul b. Prin urmare, funcţia modulului „Obtinere d” poate fi descompusă în 
două subfuncţii: obţinerea lui b care este necesar în generarea lui d, funcţie 
realizată de modulul „Obținere b”, şi transformarea lui b în d, realizată prin 
apelarea modulului „B”. Modulul de control „Obtinere d” recepționează pe d 
prin apelarea modulului B, însă el trebuie să transmită acestuia pe b, ceea ce 
justifică necesitatea prezenţei modulului „Obținere b” care va returna pe b. 
Aceeaşi manieră de descompunere va fi aplicată modulului „Obținere b”. În 
figura 3.7(a) este prezentat rezultatul descompunerii ambelor ramuri 
aferente. i 

Descompunerea ramurilor eferente se realizează asemănător. În 
diagrama fluxurilor de date din figura 3.5, fluxul de date h este transmis în 
ramura eferentă procesului G, a cărui rezultat este j. Prin urmare, funcţia 
modulului „Plasare h” va fi descompusă în două subfuncţii: producerea datei j, 
realizată de modulul G care are ca intrare data h, şi plasarea mai departe a lui 
j, realizată de modulul „Plasare j”. Astfel, modulul de control „Plasare h” va 
transmite data h modulului G care va returna pe j. Continuându-se 
descompunerea se identifică un nou modul de control, „Plasare j”. Similar se 
poate continua procesul de descompunere cu ambele ramuri eferente, 
obținându-se diagrama din figura 3.7(b). 

Ramurile transformării centrale sunt descompuse după aceleaşi reguli 
ca cele ale descompunerii funcţionale. În cazul nostru, vom avea două module 
corespunzătoare celor două procese conţinute de ramura centrală. Dacă cele 
două procese ar fi descompuse în diagrama fluxurilor de date (adică vor exista 
alte două diagrame de nivel inferior) atunci procesele din diagramele copil 
vor avea în corespondenţă module subordonate ierarhic celor două module 
din diagrama de structură. 

Transpunerea diagramelor fluxurilor de date în diagrama de structură 
nu este chiar un proces simplu, în sensul că două sau mai multe transformări 
din DFD pot fi combinate într-un singur modul sau o transformare sa fie 
descompusă în două sau mai[ Modul] module. În realizarea acestei 
descompuneri trebuie să se ţină A Eau] conceptele, mărimile de evaluarea 
a calităţii programelor (cuplare şi IN e şi regulile practice care privesc 
proiectarea programiţor, Pe” e Emh" dacă preceseln B şi C realizează 


g A A 
validarea datelor continute SĂ iR $e intrar8&%, respeetiv c (caz în care d 


reprezintă b~välid, ia zá fi c valid onstată ră cele doua operatiuni de 
valid pas t asem: Obtiner h „atunc| p Jeneral A odulele |Plasare yor fi 
înloc ntr-un Seys odul cel belat a —9de modul» i trol, 
„Obtit® A şi „Obegaeă e e”. Aceziă Şt eralizagă à donduce la ZI AN zanga 
cantijă iN cod ce tfebtiăgcrisă. d hAg j 
FE e PT e e pere Pere pe 
B 
i N 


KA 
A a Eca 
a A 


Figura 3.8 Arhitectura inițială a programului generată prin metoda analizei transformărilor 


Deşi toate aceste aspecte vor fi avute în vedere în etapa următoare, ele 
nu trebuie ignorate nici în această etapă, ele fiind utile în conceperea 
arhitecturii iniţiale a programului. 

Arhitectura iniţială obţinută trebuie completată cu o descriere narativă 
a fiecărui modul, pe baza specificaţiilor narative elaborate odată cu 
conceperea DFD. Această descriere cuprinde: descrierea interfeţelor dintre 
module (datele care intră şi care ies din fiecare modul); datele reţinute de un 
modul, cum ar fi cele stocate în structuri de date locale; descrierea 
procedurală, care evidenţiază principalele puncte decizionale şi operaţii de 
prelucrare aplicate asupra datelor; specificarea restricțiilor şi a 
caracteristicilor speciale (accesul la baza de date, caracteristicile hardware 
necesare, timpul de răspuns cerut etc.). Toate aceste descrieri vor constitui 
un prim pas către generarea specificaţiilor detaliate de proiectare. 

4. Rafinarea arhitecturii iniţiale prin aplicarea unor concepte şi 
reguli practice de proiectare care privesc îmbunătăţirea calităţii programului. 
În această etapă unele module pot fi recompuse iar altele descompuse pentru 
a se obţine o coeziune maximă, o cuplare minimă şi, implicit, o structură de 
program care să poată fi implementată, testată şi întreţinută mai uşor. De 
exemplu, dacă se constată un grad de cuplare mare datorită utilizării datelor 
globale, atunci se poate apela la gruparea modulelor care fac referire la acele 
date. 

Obiectivul metodei analizei transformărilor a vizat conceperea 
arhitecturii iniţiale a programului pornind de la diagramele fluxurilor de date. 
Odată definită, arhitectura poate fi revizuită şi îmbunătăţită datorită viziunii 
de ansamblu pe care o oferă proiectanţilor. Eventualele modificări realizate în 
acest moment nu solicită un volum prea mare de muncă, însă pot avea un 
impact profund asupra calităţii programului. Ignorarea acestei activităţi şi 
trecerea directă la scrierea programelor va face dificilă evaluarea şi rafinarea 
arhitecturii la nivel global (“nu poţi vedea pădurea din cauza copacilor”). 


3.4.1.2 Analiza tranzacţiilor 
Analiza tranzacţiilor se aseamănă cu analiza transformărilor, bazându- 


se tot pe diagramele fluxurilor de date. Diferenţa majoră dintre cele două 
strategii, după cum arată şi numele lor, constă în faptul că analiza 
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tranzacţiilor se concentrază pe centrul tranzacţional şi nu pe ramurile 
centrale de transformare. Această diferenţă se răsfrânge şi asupra structurii 
programului. 

În cazul unui sistem orientat pe tranzacţii, diagrama de structură va 
avea pe primul nivel un modul corespunzător centrului tranzacţional, pe care 
va fi reprezentat şi un romb ce indică apelarea numai a unuia dintre modulele 
situate pe nivelul inferior. Al doilea nivel ierarhic va conţine câte un modul 
pentru fiecare ramură ce se desprinde din centrul tranzacţional, astfel încât 
fiecare modul va trata o anumită tranzacţie. Modulul principal nu va face 
altceva decât să recunoască tipul tranzacţiei şi să dea controlul execuţiei 
modulului corespunzător de pe al doilea nivel. Cum de regulă alegerea unei 
tranzacţii se face prin selectarea unei opţiuni dintr-un meniu, acest modul va 
prelua opţiunea utilizatorului în funcţie de care va decide cărui modul îi va da 
controlul. Fiecare modul de pe al doilea nivel cunoaşte detaliile unei tranzacţii 
anume, dar nu ţine cont de celelalte tranzacţii, respectiv de ceea ce fac 
celelalte module. 

Prelucrările propriu-zise specifice fiecărei tranzacţii sunt realizate de 
modulele situate pe al treilea nivel, care vor fi apelate de modulele de control 
a tranzacţiilor (cele de pe al doilea nivel). La conceperea modulelor de pe 
acest nivel vor fi avute în vedere avantajele prelucrării similitudinilor, motiv 
pentru care va fi foarte probabil ca un modul de pe nivelul trei să poată fi 
apelat de mai multe dintre modulele de pe nivelul doi (adică acelaşi modul va 
fi apelat în cazul execuţiei mai multor tipuri de tranzacţii). Forma generală a 
diagramei de structură pentru un sistem orientat pe tranzacţii este prezentată 


în figura 3.9. 
Centrul 
tranzacţio 


Modul 
operaţie 1 


Modul 
operaţie 5 


Figura 3.9 Forma generală a diagramei de structură pentru sistemele orientate pe tranzacții 


Ca şi în cazul strategiei anterioare, vom apela mai întâi la un exemplu 
abstract, pentru a pune în evidenţă mai bine aspectele particulare ale metodei 
analizei tranzacţiilor (fig. 3.10). 


~ 


Figura 3.10 Modelul general al unei diagrame a fluxurilor de date orientate pe tranzacții 


1. Identificarea centrului tranzacţional şi a  caracteristicii 
fluxurilor informaţionale pentru fiecare cale de acţiune. Localizarea 
centrului tranzacţional poate fi realizată relativ uşor în diagrama fluxurilor de 
date, el fiind reprezentat ca un proces din care vor deriva mai multe fluxuri 
informaţionale, câte unul pentru fiecare cale de acţiune (adică pentru fiecare 
tip de tranzacţie). In figura 3.10, procesul D reprezintă centrul tranzacţional, 
el fiind delimitat de cele două fluxuri de intrare, pe de o parte, şi de cele trei 
căi de acţiune, pe de altă parte. După această delimitare, fiecare cale de 
acţiune trebuie analizată pentru a se identifica caracteristicile proprii; unele 
ramuri pot fi orientate pe transformări, iar altele pe tranzacţii. Existenţa mai 
multor centre tranzacţionale într-o diagramă a fluxurilor de date denotă faptul 
că în sistemul respectiv pot fi identificate clase şi subclase de tranzacţii. De 
exemplu, ramura corespunzătoare căii de acţiune derivate din procesul D prin 
fluxul f are drept caracteristică orientarea pe transformări: procesele E şi F 
formează ramura aferentă, procesul G reprezintă ramura centrală de 
transformare, iar procesul H este un proces eferent. Ulterior,la construirea 
diagramei de structură, se va ţine cont de caracteristica identificată pentru 
fiecare ramură şi se va aplica metoda corespunzătoare. 
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Figura 3.11 Arhitectura inițială obținută prin metoda analizei transformărilor 


Herr 


AN 


2. Maparea DFD într-o structură de program orientată pe 
prelucrarea tranzacţiilor. Ramura sau ramurile de intrare în centrul 
tranzacțional vor fi descompuse după regulile analizei transformărilor, 
pornind de la centrul tranzacţional, ceea ce explică existența celor două 
module de control, „Obtinere c” şi „Obținere e”. Se continuă prin adăugarea 
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unui modul de control corespunzător centrului tranzacţional, căruia îi vor fi 
subordonate câte un modul pentru fiecare cale de acţiune corespunzătoare 
unui tip de tranzacţie. În exemplul nostru, modulul D reprezintă modulul de 
control pentru selectarea tranzacţiei ce va fi executată, iar modulele T1, T2 şi 
T3 sunt modulele de control pentru fiecare din cele trei tipuri de tranzacţii. 
Rezultatul primei descompuneri a DFD din figura 3.10 este prezentată în 
figura 3.11 (numai modulele situate deasupra liniei orizontale). 

3. Detalierea diagramei de structură prin descompunerea 
ramurii sau ramurilor de intrare şi a ramurilor aferente căilor de 
acţiune. Fluxurile informaţionale de intrare în centrul tranzacţional vor fi 
descompuse conform cu metoda analizei transformărilor, iar fluxurile 
informaţionale aferente căilor de acţiune vor fi descompuse conform cu 
metoda corespunzătoare caracteristicii identificate pentru fiecare ramură în 
parte. După cum se observă, modulele „Obținere c” şi „Obținere e”, 
responsabile pentru furnizarea intrărilor în centrul tranzacţional (c şi e), au 
fost descompuse la fel ca în exemplul prezentat la analiza transformărilor. De 
asemenea, întru-cât fluxurile din ramura corespunzătoare modulului T1 sunt 
orientate pe transformări, acesta a fost descompus tot după metoda analizei 
transformărilor. Arhitectura iniţială a programului, rezultată în urma celei de- 
a doua descompunere, este prezentată în figura 3.11. 

4. Rafinarea arhitecturii iniţiale prin aplicarea conceptelor şi 
regulilor practice de proiectare care privesc îmbunătăţirea calităţii 
programului. Acest pas este identic cu cel din analiza transformărilor. 


3.4.2 Cuplarea şi coeziunea 


Calitatea uni program este apreciată în funcţie de uşurinţa 
implementării, testării, întreţinerii şi modificării lui. Obţinerea unui program 
de calitate este condiţionată de o bună proiectare arhitecturală, care are la 
bază conceptul de independenţă funcțională. 

Conceptul de independenţă funcţională derivă din principiul „divide et 
impera” şi principiul abstractizării, prezentate anterior. El presupune ca 
fiecare modul de program să fie proiectat astfel încât el să realizeze o singură 
funcţie sau subfuncţie a programului, iar interfaţa cu celelalte module să fie 
cât mai simplă. Avantajele creării de module independente constau în: 

> uşurinţa dezvoltării lor (mai ales în condiţiile lucrului în echipă) 
deoarece proiectantul se concentrează asupra realizării unei 
singure funcţii, 

> limitarea efectelor secundare generate de modificarea codului sau 
a specificaţiilor de proiectare, 

> facilitarea definirii cazurilor de test, 

> posibilitatea reutilizării unor module în cazul modificării 
sistemului. 

Independenţa funcţională este măsurată prin intermediul a două criterii 
calitative: coeziunea şi cuplarea. Coeziunea este o măsură a afinităţii 
mutuale dintre componentele unui modul, respectiv a modului în care 
instrucţiunile dintr-un modul sunt folosite pentru realizarea unei singure 
funcţii. Este de dorit ca gradul de coeziune a unui modul să fie cât mai ridicat. 
Cuplarea este o măsură a interdependenţei relative dintre module, ea 
depinzând de complexitatea interfeţei dintre module. Este de dorit ca 
interfaţa dintre module să fie cât mai simplă, deci gradul de cuplare să fie cât 
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mai redus. Aşadar, se poate spune că prin coeziune se evaluează legăturile 
interne ale componentelor unui modul, în timp ce prin cuplare sunt vizate 
legăturile externe ale unui modul. 


3.4.2.1 Coeziunea 


După cum a fost definită anterior, coeziunea presupune ca fiecare 
instrucţiune dintr-un modul să fie legată de realizarea funcţiei specificată 
pentru acesta. În mod ideal, ar trebui ca un modul să realizeze o singură 
funcţie (sarcină) în cadrul programului. 

Există mai multe tipuri de coeziune ce formează un spectrum. În 
ordinea valorii lor, de la cea mai bună la cea mai slabă, ele sunt: funcţională, 
secvenţială, comunicaţională, procedurală, temporală, logică şi coincidentală. 
Scala spectrumului coeziunii este neliniară, în sensul că tipurile de coeziune 
cele mai slabe sunt mult mai „rele” decât tipurile de coeziune medii care sunt 
„destul de bune” în comparaţie cu tipurile de coeziune cele mai bune. 

La limita superioară a spectrumului se află coeziunea funcţională, 
care presupune ca toate instrucţiunile dintr-un modul să realizeze împreună o 
singură sarcină sau funcţie bine definită. În cele mai multe cazuri, coeziunea 
funcţională poate fi evidenţiată prin numele atribuit modulului respectiv, dacă 
acesta conţine un singur verb şi un singur obiect, ca de exemplu: 
CALCUL DOBÂNDĂ, CALCUL IMPOZIT SALAR, ACTUALIZARE STOC. 
Această caracteristică este valabilă pentru modulele aflate pe nivelurile 
inferioare ale structurii ierarhice a programului, dar nu şi pentru modulele 
situate pe nivelurile superioare care au ca rol controlul execuţiei programului, 
în primul rând, şi nu realizarea unor sarcini elementare. De exemplu, modulul 
CALCUL SPORURI REŢINERI SALARII este un modul de control a cărui 
funcţie constă în apelarea modulelor subordonate ierarhic într-o anumită 
succesiune, fiecare modul subordonat realizând calculul unui anumit tip de 
spor sau de reţinere. Prin urmare, se poate spune că modulul de control 
CALCUL SPORURI REŢINERI SALARII este unul puternic funcţional. 

Comportamentul modulelor cu coeziune funcţională este tipic cutiei 
negre, în sensul că ele vor putea fi apelate fără a se cunoaşte detaliile 
procedurale interne, cunoscându-se doar intrările şi ieşirile din modul. 
Adesea, un modul caracterizat de coeziune funcţională transformă o singură 
intrare într-o singură ieşire. 

Dincolo de coeziunea funcţională, celelalte tipuri de coeziune presupun 
ca un modul să realizeze mai multe funcţii grupate pe anumite considerente. 
Coeziunea secvenţială presupune gruparea a două sau mai multe funcţii ce 
au în comun prelucrarea aceleiaşi structuri de date, în sensul că ele 
realizează transformări succesive asupra structurii de date care constituie 
intrarea în modulul respectiv. Rezultatul unei funcţii de prelucrare va 
reprezenta intrarea pentru funcţia următoare. Aşadar, prima funcţie 
(operaţie) va prelucra structura de date iniţială, după care rezultatul 
transformării va constitui intrare pentru a doua funcţie, iar la rândul ei ieşirea 
celei de-a doua funcţie va constitui intrarea pentru cea de-a treia funcţie 
ş.a.m.d. Rezultatul obţinut prin aplicarea ultimei funcţii va reprezenta ieşirea 
modulului respectiv. Coeziunea secvenţială este evidenţiată în DFD atunci 
când se remarcă o structură compactă de mai multe procese de prelucrare 
aplicate succesiv asupra unui flux de date. 
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Multiplele funcţii pe care le realizează un modul caracterizat de 
coeziune secvenţială fac dificilă întreţinerea acestuia. Însă, dezavantajul cel 
mai important este legat de limitarea reutilizării unei funcţii interne a acestui 
modul de către celelalte module din sistem. Acceptarea acestui tip de 
coeziune poate fi justificată de reducerea complexităţii interfeţelor dintre 
modulele ce s-ar obţine prin descompunerea modulului, respectiv evitarea 
abuzului în utilizarea de variabile globale. Oricum, eventualele probleme 
cauzate de coeziunea secvenţială pot fi înlăturate prin descompunerea 
modulului respectiv în două sau mai multe module subordonate ierarhic. 

Într-un modul caracterizat de coeziune comunicaţională, multiplele 
funcţii pe care le realizează sunt legate între ele tot prin datele pe care 
modulul le utilizează însă, spre deosebire de coeziunea secvenţială, 
succesiunea funcţiilor nu este importantă. Fiecare instrucţiune dintr-un modul 
cu coeziune comunicaţională operează asupra aceloraşi date de intrare sau 
privesc aceleaşi date de ieşire. 

Cu cât se înaintează în spectrumul coeziunii cu atât ne îndepărtăm mai 
mult de coeziunea funcţională, iar modulele sunt din ce în ce mai greu de 
întreţinut şi de testat. În cazul coeziunii procedurale, multiplele funcţii ale 
unui modul sunt grupate pe baza fluxului de control din cadrul programului 
care dictează modul în care se realizează transferul controlului execuţiei 
programuluide la o funcţie internă la alta. De exemplu, în cazul unei structuri 
de control secvențiale funcţiile interne ale modulului trebuie realizate într-o 
anumită succesiune. Bineînţeles, pot interveni şi celelalte două structuri de 
control standard, alternativă şi repetitivă, pentru definirea secvenţei de 
execuţie a funcţiilor interne. 

Modulele caracterizate de coeziune temporală grupează mai multe 
funcţii între care nu există altă legătură decât cea legată de factorul timp, în 
sensul că toate trebuie executate la un anumit moment dat, fără ca secvenţa 
de execuţie a lor să prezinte importanţă. Cele mai cunoscute exemple sunt 
modulele de iniţializare şi cele de finalizare a programelor. La lansarea unui 
program, un modul poate fi conceput pentru a realiza iniţializarea variabilelor 
de memorie, deschiderea fişierelor de lucru necesare, configurarea mediului 
de lucru etc. Modulele cu coeziune temporală sunt dificil de întreţinut datorită 
nu numai multiplelor funcţii pe care le realizează dar şi gradului mare de 
cuplare cu alte module din sistem. Astfel, momemtul execuţiei funcţiilor de 
iniţializare nu poate fi modificat deoarece poate afecta corectitudinea 
execuţiei altor module. 

În următorul tip de coeziune, coeziunea logică, legăturile dintre 
instrucţiunile unui modul sunt foarte slabe. Elementele unui astfel de modul 
sunt grupate împreună prin includerea lor într-o categorie generală, 
urmărindu-se evitarea redundanţei în scrierea codului. Modulele cu coeziune 
logică implică un grad mare de cuplare, ordinea de execuţie a instrucţiunilor 
dintr-un astfel de modul fiind dictată din afară prin intermediul unei informaţii 
de control ce va reprezenta intrare în modul. Prin urmare, aceste module nu 
vor mai funcţiona pe principiul cutiei negre, întru-cât modulul apelant trebuie 
să cunoască logica internă a modulului apelat în vederea selectării funcţiilor 
care urmează a fi utilizate la un moment dat în cadrul secvenţei de execuţie. 

Fişierele DLL din mediul WINDOWS sunt, în cele mai multe cazuri, 
proiectate să fie logic coezive. De exemplu, fişierul COMMDLG.DLL conţine 
instrucţiunile pentru configurarea căsuţelor de dialog activate la utilizarea 
opţiunilor File Open, File Save, Search şi Print. Avantajul unei astfel de 
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abordări constă în oferirea unei interfeţe unice pentru întreaga aplicaţie şi 
scrierea de cod mai puţin. Numai că, dacă proiectantii unei aplicaţii în mediul 
WINDOWS doresc să nu se limiteze la facilităţile oferite de COMMDLG.DLL, 
vor trebui să scrie propriul cod pentru a adăuga noi facilităţi. Ori, acest lucru 
este imposibil de realizat fără a dezmembra o bună parte a logicii 
programului. 

Tipul de coeziune cel mai puţin de dorit este coeziunea coincidentală. 
Ea se manifestă atunci când între elementele unui modul există puţine 
legături sau chiar nici o legătură. Toate funcţiile pe care le realizează modulul 
au fost grupate cu totul întâmplător ca urmare a neatenţiei proiectantului cu 
privire la conceptul de coeziune sau din dorinţa acestuia de a economisi timp 
cu activităţile de proiectare şi programare. În mod normal, modulele cu 
coeziune coincidentală sunt foarte rar întâlnite (sau cel puţin ar trebui). 
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Figura 3.12 Tipurile de coeziune 


Page-Jones a dezvoltat o diagramă foarte utilă pentru înțelegerea 
tipurilor de coeziune, el ordonându-le într-un arbore decizional prezentat în 
figura 3.12. Mai întâi se pune întrebarea dacă modulul realizează o singură 
funcție. Dacă da, atunci modulul este caracterizat de coeziune funcțională, iar 
dacă nu se caută să se afle ce anume leagă între ele multiplele functii pe care 
le realizează modulul. Dacă legătura dintre funţii are la bază datele, atunci se 
verifică dacă secvenţa de execuţie a funcţiilor este importantă, în funcţie de 
care pot exista două posibilităţi: dacă secvenţa prezintă importanţă, atunci 
avem o coeziune secvenţială, altfel coeziunea este comunicaţională. În cazul 
în care fluxul de control este cel care a dus la gruparea funcţiilor într-un 
singur modul, se va verifica de asemenea importanţa secvenţei de execuţie a 
funcţiilor respective, fiind posibile tot două variante: în cazul în care secvenţa 
prezintă importanţă, coeziunea va fi procedurală, altfel va fi temporală. În 
sfârşit, dacă nici una din cele două motivații de grupare a funcţiilor nu este 
valabilă, atunci se va pune întrebarea dacă toate funcţiile fac parte din 
aceeaşi categorie generală. În funcţie de răspunsul la această ultimă 
întrebare putem avea coeziune logică sau coincidentală. 
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În practică, nu este necesară stabilirea tipului de coeziune pentru 
fiecare modul, ci este necesară înţelegerea deplină a conceptului în vederea 
recunoaşterii şi evitării tipurilor de coeziune cele mai slabe. Ar fi ideal ca 
toate modulele unui program să fie caracterizate de coeziune funcţională, însă 
practic acest lucru este imposibil. În general, gradul de coeziune a modulelor 
diferă în funcţie de nivelul ierarhic pe care se situează. Modulele localizate în 
partea superioară a structurii programului îndeplinesc cu preponderență 
funcţii decizionale privind modulele care vor fi apelate, parametrii care 
trebuie transmişi şi momentul în care trebuie transmişi. Spre deosebire de 
acestea, modulele situate pe ultimile niveluri ierarhice nu au responsabilităţi 
decizionale, ci numai de realizare a unor operaţii: ele preiau intrarea, execută 
funcţia lor şi transmit ieşirea modulelor apelante. Modulele situate pe 
nivelurile de mijloc ale arhitecturii programelor îndeplinesc atât 
responsabilităţi decizionale cât şi realizarea unor operaţii. 


3.4.2.2 Cuplarea 


Cuplarea defineşte gradul de interdependenţă dintre două sau mai 
multe module de program. Proiectanţii care concep arhitectura sistemului 
trebuie să urmărească minimizarea interdepedenţelor dintre module, adică 
reducerea cât mai mult posibil a gradului de cuplare. Cu cât gradul de cuplare 
este mai mare cu atât este mai mare probabilitatea propagării erorilor de la 
un modul la altul, precum şi probabilitatea apariţiei unor efecte neaşteptate 
sau nedorite asupra modulelor care sunt dependente de un altul a cărui cod 
este modificat. 

Ca şi în cazul coeziunii, există câteva tipuri de cuplare ce pot fi 
eşalonate în funcţie de gradul mai mare sau mai redus de dependenţă dintre 
module. 

Tipul de cuplare cel mai de dorit îl reprezintă cuplarea prin date 
elementare (data coupling), caz în care dependenţa dintre module este 
mult redusă deoarece cele două module îşi transmit doar datele elementare 
necesare pentru ca fiecare să-şi realizeze funcţia pentru care au fost 
proiectate. Altfel spus, nici un modul nu va fi interesat de detaliile 
procedurale interne ale modulelor cu care interacționează, ceea ce sugerează 
şi o bună coeziune a fiecărui modul în parte. 

Un exemplu comun de cuplare prin date elementare îl reprezintă 
facilitatea DDE (Data Dynamic Exchange) din mediul Windows. 

Atunci când datele transmise între două module sunt sub forma unei 
structuri de date sau chiar a unei înregistrări întregi, vom avea o cuplare 
prin date grupate (stamp coupling). Spre deosebire de tipul de cuplare 
anterior, în acest caz creşte gradul de interdependenţă dintre module 
deoarece, în cele mai multe situaţii, nu toate datele elementare ce compun 
structura de date sau înregistrarea transmisă sunt necesare în execuţia 
modulului apelat. O simplă modificare a structurii de date va afecta toate 
modulele cu care vine în legătură, chiar dacă unele din aceste module nu 
apelează la partea modificată. Acest tip de cuplare nu ar fi criticabil dacă 
toate datele elementare din structură ar fi valorificate de către modulele care 
le preiau. 

Cuplarea prin informaţii de control (control coupling) apare 
atunci când un modul transferă informaţii de control altui modul. Informaţiile 
de control (flag) sunt acele date elementare ce pot lua anumite valori bine 


22 


definite dintr-un domeniu finit de valori (cel mai comun exemplu îl constituie 
datele elementare de tip logic, care pot lua doar una din valorile TRUE şi 
FALSE), în funcţie de care modul căruia îi sunt transmise va executa un grup 
de instrucţiuni sau altul. Prin urmare, modulul apelant trebuie să cunoască în 
bună măsură detaliile procedurale interne ale modulului apelat pentru a-i 
transmite controlul. Ori, atât timp cât modulul apelant este interesat de 
detaliile interne ale modulului apelat, este evident că gradul de 
interdependenţă dintre cele două module este destul de mare. 

Cuplarea prin informaţii de control prezintă o particularitate, în sensul 
că un modul situat pe un nivel ierarhic inferior poate fi proiectat astfel încât, 
după ce şi-a realizat sarcina, să transfere controlul execuţiei programului 
către modulul apelant, spunându-i acestuia ce să facă şi când să facă. În acest 
caz avem de-a face cu o inversare a autorităţii, deoarece subordonatul îi 
spune superiorului ce trebuie să facă. 

Cele trei tipuri de cuplare prezentate până acum sunt cele mai des 
întâlnite în proiectarea programelor. Deşi sunt întâlnite foarte rar astăzi, mai 
există două tipuri de cuplare: cuplarea prin date comune şi cuplarea prin 
conţinut. 

Cuplarea prin date comune (common coupling) intervine atunci 
când două sau mai multe module accesează aceleaşi date elementare aflate 
într-un loc comun, numit şi zona datelor globale. Existenţa unei astfel de zone 
este obişnuită în limbajele de programare din generaţia a treia, precum 
FORTRAN şi COBOL (de exemplu orice program COBOL conţine o zonă 
numită DATA DIVISION în care vor fi declarate toate variabilele ce vor fi 
utilizate de instrucţiunile de program din zona PROCEDURE DIVISION), însă 
ea poate fi creată şi în limbajele de generaţia a patra. De fapt, o dată definită 
într-o astfel de zonă va fi de tip global şi va fi putea fi referită de orice modul 
din program. Sigur că gradul de dependenţă în cazul cuplării prin date 
comune este foarte mare, atât timp cât orice eroare sau modificare în zona 
datelor comune afectează toate modulele programului care utilizează date din 
această zonă. 

Ultimul tip de cuplare, cuplarea prin conţinut (content coupling), 
apare atunci când un modul modifică detaliile procedurale ale altui modul. 
Acest tip de cuplare era caracteristic limbajelor mai vechi de programare, ea 
nemaifiind permisă în limbajele de nivel înalt. 

Înainte de a încheia discuţiile despre cuplarea modulelor, trebuie spus 
că ea nu este comutativă. De exemplu, modulul A poate să transmită o dată 
elementară modulului B, în timp ce modulul B poate returna o informaţie de 
control. Aşadar, vom avea o cuplare prin date elementare între modulele A şi 
B, şi o cuplare prin informaţii de control între modulele B şi A. 

Cuplarea şi coeziunea sunt caracteristici duale, în sensul că cu cât 
coeziunea modulelor unui program este mai bună, cu atât gradul de cuplare 
dintre module va fi mai redus. De aceea, la rafinarea arhitecturii sistemului 
informatic cele două caracteristici trebuie analizate împreună atunci când 
proiectanţii sunt în faţa unei decizii. 

Cuplarea şi coeziunea prezintă o importanţă crucială în proiectarea 
sistemelor informatice, demonstrată prin următoarele argumentet: 

> Se reduce comunicarea între membrii echipei de dezvoltare a 
sistemului, deoarece permite luarea unor decizii la nivel local fără 
a se interfera cu deciziile şi activităţile care privesc alte module; 


5 Van Vliet, H., Software Engineering. Principles and Practice, John Wiley & Sons, 2000 
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> Se reduce probabilitatea propagării modificării unui modul către 
alte module, ceea ce reduce costurile întreţinerii; 

> Sporeşte gradul de reutilizabilitate a modulelor, în cazul 
reproiectării sistemului sau a proiectării unui nou sistem 
asemănător; 

> Creşte inteligibilitatea modulelor; oamenii au o capacitate de 
memorie limitată, iar simplitatea interfeţelor dintre module 
facilitează înțelegerea unei componente a programului 
independent de contextul în care este utilizată; 

> Studiile empirice arată că proiectele caracterizate de o coeziune 
puternică şi o cuplare redusă sunt mai puţin supuse erorilor. 

Pe lângă aceste avantaje mai trebuie amintit unul, cel puţin la fel de 
important: programele caracterizate de coeziune maximă şi cuplare minimă 
sunt mult mai uşor de testat, după cum se va vedea în capitolul consacrat 
testării sistemelor informatice. 


Notă. Exemple pentru tipurile de cuplare şi coeziune vor fi date la curs. 
3.4.3 Reguli practice privind îmbunătăţirea arhitecturii programelor 


După ce structura modulară a programului a fost definită prin aplicarea 
conceptelor de proiectare prezentate anterior, ea poate fi îmbunătăţită prin 
reanalizarea diagramei de structură şi aplicarea următoarelor reguli 
practice”: 

e Evaluarea structurii programului în vederea reducerii cuplării şi 
îmbunătăţirii coeziunii. În scopul sporirii independenţei funcţionale a 
modulelor, acestea pot fi descompuse sau recompuse. Necesitatea 
descompunerii modulelor apare atunci când există prelucrări comune 
două sau mai multor module, ceea ce impune redefinirea acestor 
prelucrări ca module separate coezive. De asemenea, în cazul modulelor 
cu un grad mare de cuplare se poate realiza unirea lor în unul singur 
ceea ce are ca efect reducerea complexităţii interfeţei, a fluxurilor de 
control şi a referinţelor la date globale. 

e  Minimizarea structurilor în care un modul are în sfera sa de control 
prea multe module. De regulă, odată cu creşterea nivelului de detaliere 
creşte şi numărul fan-in. 

e Mentinerea sferei efectelor unui modul în limita sferei sale de control. 
Sfera efectelor unui modul cuprinde toate modulele care sunt afectate 
de o decizie localizată în modulul respectiv. Sfera de control este 
formată din toate modulele subordonate ierarhic modulului respectiv. 

e Evaluarea interfeţelor dintre module în vederea reducerii complexităţii 
şi a redundanţei. Complexitatea interfeţelor reprezintă principala cauză 
a erorilor de programare. Interfeţele trebuie proiectate astfel încât să 
fie transmise de la un modul la altul numai informaţiile semnificative 
pentru funcţiile celor două module. Ignorarea acestei cerinţe reprezintă 
un semn al slabei coeziuni dintre module, ceea ce presupune revizuirea 
lor. 

e Definirea de module a căror funcţii sunt uşor de intuit şi evitarea celor 
restrictive. Modulele intuitive pot fi tratate după principiul cutiei negre , 


7 Presmann, R.S., Software Engineering. A practitioner's Approach, McGraw-Hill, 2000, 
p.348-350 
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ceea ce înseamnă că va avea aceleaşi ieşiri indiferent de detaliile 
prelucrărilor interne. Un modul care se limitează la prelucrările 
specifice unei subfuncţii demonstrează o bună coeziune. 


Principiile filozofiei structurate au fost desprinse din practici care 
existau deja, dar care nu au fost formalizate şi standardizate până la apariţia 
tehnicilor structurate. Aceste principii sunt: 

1. Principiul “împarte şi stăpâneşte”, introdus odată cu programarea 
modulară, presupune descompunerea unei probleme complexe în mai 
multe probleme independente mai mici, a căror înţelegere şi rezolvare este 
mai simplă. Aplicarea acestui principiu în dezvoltarea programelor 
presupune descompunerea lui, imaginară sau reală, în mai multe 
componente ce pot fi uşor proiectate şi testate separat, fără a ţine seama 
de numeroasele detalii ale întregului program. Se obţine un program 
modular prin aplicarea, cel mai adesea, a unei descompuneri funcţionale. 

2. Principiul abstractizării. Abstractizarea permite descrierea a ceea ce 
trebuie făcut şi nu cum trebuie făcut, oferind soluţiile cele mai bune de 
rezolvare a problemei, fără luarea în considerare a aspectelor detaliate şi 
irelevante ale realităţii. În acest mod se realizează o mai bună stăpânire a 
complexităţii, prin structurarea programelor pe mai multe niveluri de 
abstractizare. Primul nivel al unui program este cel mai abstract şi oferă o 
imagine simplificată a acestuia, exprimată printr-o singură funcţie sau 
instrucţiune, în timp ce pe ultimul nivel se găsesc detaliile. Parcurgând în 
jos programul, componentele acestuia sunt descrise cu detalii din ce în ce 
mai multe. 

3. Principiul formalizării impune utilizarea unei abordări riguroase, 
metodice în elaborarea produselor-program, iar rezultatul aplicării acestui 
principiu este conceptul de ciclu de viaţă. Ciclul de viaţă al unui produs- 
program este definit ca o succesiune de faze ce trebuie parcurse pentru 
elaborarea lui, în care fiecare fază este formată din mai multe activităţi. 

4. Principiul ordonării ierarhice este strâns legat de principiul “împarte şi 
stăpâneşte” şi presupune nu doar descompunerea programului în părţi 
componente, ci şi aranjarea lor într-o structură ierarhică sub formă 
arborescentă. Prin această ordonare se obţine un plus de inteligibilitate a 
programelor elaborate. Introducerea principiului ordonării ierarhice 
diferenţiază programarea structurată de programarea modulară, structura 
ierarhică reprezentând una din principalele evoluţii faţă de programarea 
modulară. Structura ierarhică reprezintă un mecanism puternic de creare 
a programelor uşor modificabile, deoarece permite eventuala renunțare la 
modulele situate pe un nivel, astfel încât modulele situate pe nivelurile 
inferioare să rămână utilizabile şi să constituie baza unui nou program. 

Arhitectura programului obţinută prin maparea transformărilor şi/sau a 
tranzacţiilor trebuie completată cu o documentaţie care conţine: 


. Descrierea narativă a fiecărui modul (operaţiunile de 
prelucrare, momentele decizionale şi operaţiunile de 
citire/scriere. 

° Descrierea interfețelor interne dintre module, interfețele 
externe ale sistemului cu alte sisteme şi a interfețelor om- 
calculator. 

. Definirea structurilor de date globale şi locale. 
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. Specificarea restricţiilor şi/sau a limitelor fiecărui modul 
(restricţii privind tipul şi formatul datelor; limitările privind 
memoria şi timpul de răspuns; cazurile speciale neluate în 
considerare. 
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